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Abstract 


This document specifies a restricted profile of the Internet 
multimedia messaging protocols for use between voice processing 
server platforms. The profile is referred to as the Voice Profile 
for Internet Mail (VPIM) in this document. These platforms have 
historically been special-purpose computers and often do not have the 
same facilities normally associated with a traditional Internet 
Email-capable computer. As a result, VPIM also specifies additional 
functionality, as it is needed. This profile is intended to specify 
the minimum common set of features to allow interworking between 
conforming systems. 


This document obsoletes RFC 2421 and describes version 2 of the 
profile with greater precision. No protocol changes were made in 
this revision. A list of changes from RFC 2421 are noted in Appendix 
F. Appendix A summarizes the protocol profiles of this version of 
VPIM. 
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Introduction 


MIME is the Internet multipurpose, multimedia-messaging standard. 
This document explicitly recognizes its capabilities and provides a 
mechanism for the exchange of various messaging technologies, 
primarily voice and facsimile. 


Voice messaging evolved as telephone answering service into a full 
send, receive, and forward messaging paradigm with unique message 
features, semantics and usage patterns. Voice messaging was 
introduced on special purpose computers that interface to a telephone 
switch and provide call answering and voice messaging services. 
Traditionally, messages sent from one voice messaging system to 
another were transported using analog networking protocols based on 
DTMF signaling and analog voice playback. As the demand for 
networking increases, there was a need for a standard high-quality 
digital protocol to connect these machines. VPIM has successfully 
demonstrated its usefulness as this new standard. VPIM is widely 
implemented and is seeing deployment in customer networks. This 
document clarifies ambiguities found in the earlier specification and 
is consistent with implementation practice. The profile is referred 
to as Voice Profile for Internet Mail (VPIM) in this document. 


This document specifies a restricted profile of the Internet 
multimedia messaging protocols for use between voice processing 
server platforms. These platforms have historically been special- 
purpose computers and often do not have the same facilities normally 
associated with a traditional Internet Email-capable computer. As a 
result, VPIM also specifies additional functionality, as it is 
needed. This profile is intended to specify the minimum common set 
of features to allow interworking between conforming systems. 


This document obsoletes RFC 2421 and describes VPIM version 2 of with 
greater precision. No protocol changes were made in this revision. 

A list of changes from RFC 2421 are noted in Appendix F. Appendix A 
summarizes the protocol profiles of this version of VPIM. 


1. Voice Messaging System Limitations 


The following are typical limitations of voice messaging platforms 
that were considered in creating this baseline profile. 


1) Text messages are not normally received and often cannot be 
easily displayed or viewed. They can often be processed only via 
text-to-speech or text-to-fax features not currently present in 
many of these machines. 
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2) Voice mail machines usually act as an integrated Message 
Transfer Agent, Message Store and User Agent. There is typically 


no relaying of messages. RFC822 header fields may have limited 
use in the context of the limited messaging features currently 
deployed. 


3) Voice mail message stores are generally not capable of 
preserving the full semantics of an Internet message. As such, 
use of a voice mail machine for gatewaying is not supported. In 
particular, storage of recipient lists, "Received:" lines, and 
"Message-ID:" may be limited. 


4) Internet-style distribution/exploder mailing lists are not 
typically supported. Voice mail machines often implement only 
local alias lists, with error-to-sender and reply-to-sender 
behavior. Reply-all capabilities using a Cc list are not generally 
available. 


5) Error reports must be machine-parsable so that helpful 
responses can be voiced to users whose only access mechanism is a 
telephone. 


6) The voice mail systems generally limit address entry to 16 or 
fewer numeric characters, and normally do not support alphanumeric 
mailbox names. Alpha characters are not generally used for 
mailbox identification, as they cannot be easily entered from a 
telephone terminal. 


It should be noted that newer systems are based natively on SMTP/MIME 
and do not suffer these limitations. In particular, some systems may 
support media other than voice and fax. 


1.2. Design Goals 


It is a goal of this profile to make as few restrictions and 
additions to the existing Internet mail protocols as possible while 
satisfying the requirements for interoperability with current 
generation voice messaging systems. This goal is motivated by the 
desire to increase the accessibility to digital messaging by enabling 
the use of proven existing networking software for rapid development. 


This specification is intended for use on a TCP/IP network; however, 
it is possible to use the SMTP protocol suite over other transport 
protocols. The necessary protocol parameters for such use are 
outside the scope of this document. 
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This profile is intended to be robust enough to be used in an 
environment, such as the global Internet, with installed-base 
gateways that do not understand MIME. Full functionality, such as 
reliable error messages and binary transport, will require careful 
selection of gateways (e.g., via MX records) to be used as VPIM 
forwarding agents. Nothing in this document precludes use of 
general-purpose MIME email packages to read and compose VPIM 
messages. While no special configuration is required to receive VPIM 
conforming messages, some may be required to originate conforming 
structures. 


It is expected that a system administrator who can perform TCP/IP 
network configuration will manage a VPIM messaging system. When 
using facsimile or multiple voice encodings, it is suggested that the 
system administrator maintain a list of the capabilities of the 
networked mail machines to reduce the sending of undeliverable 
messages due to lack of feature support. Configuration, 
implementation and management of these directory-listing capabilities 
are local matters. 


1.3. Applicability for VPIM 


VPIM is intended for the exchange of voice messages between 
traditional voice messaging systems and for systems that need to 
interoperate with such systems. VPIM is intended connect voice- 
messaging systems into special-purpose voice messaging networks. 
VPIM may also be used between message store servers and VPIM-aware 
clients such as web servers, TUI, and GUI clients. VPIM is not 
intended or optimized for downloading to, or sending from commercial 
email clients. 


Internet Voice Messaging, the subject of a separate standards 
initiative, is intended to enable general-purpose email clients to 
send and receive voice content through general-purpose message stores 
in an interoperable way. IVM may also be a suitable format for 
downloading voice messages from a VPIM server to a commercial email 
client. It may also be a suitable format for submission of a voice 
message from a general-purpose client into a VPIM system. 


2. Requirements Language 
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOI", 


"SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this 
document are to be interpreted as described in [REO]. 
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Protocol Restrictions 


This protocol does not limit the number of recipients per message. 
Where possible, server implementations should not restrict the number 
of recipients in a single message. It is recognized that no 
implementation supports unlimited recipients, and that the number of 
supported recipients may be quite low. 


This protocol does not limit the maximum message length. 
Implementers should understand that some machines will be unable to 
accept excessively long messages. A mechanism is defined in [SIZE] 
to declare the maximum message size supported. 


The following sections describe the restrictions and additions to 
Internet mail protocols that are required to be conforming with this 
VPIM v2 profile. Though various SMTP, ESMTP and MIME features are 
described here, the implementer is referred to the relevant RFCs for 
complete details. The table in Appendix A summarizes the protocol 
details of this profile. 


Voice Message Interchange Format 


The voice message interchange format is a profile of the Internet 
Mail Protocol Suite. Any Internet Mail message containing the format 
defined in this section is referred to as a VPIM Message in this 
document. As a result, this document assumes an understanding of the 
Internet Mail specifications. Specifically, VPIM references 
components from the message format standard for Internet messages 
[RFC822], the Multipurpose Internet Message Extensions [MIME1-5], the 
X.400 gateway specification [X.400], and the delivery status and 
message disposition notifications [REPORT] [DSN] [DRPT] [STATUS] [MDN]. 


MIME, introduced in [MIME1], is a general-purpose message body format 
that is extensible to carry a wide range of body parts. It provides 

for encoding binary data so that it can be transported over the 7-bit 
text-oriented SMTP protocol. This transport encoding (denoted by the 
"Content-Transfer-Encoding:" MIME field) is in addition to the audio 

encoding required to generate a binary object. 


MIME defines two transport-encoding mechanisms to transform binary 
data into a 7-bit representation, one designed for text-like data 
("Quoted-Printable"), and one for arbitrary binary data ("Base64"). 
While Base64 is dramatically more efficient for audio data, either 
will work. Where binary transport is available, no transport 
encoding is needed, and the data can be labeled as "Binary". 
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4.1.  VPIM Message Addressing Formats 


VPIM addresses SHALL use the RFC 822 format based on the Domain Name 
System. This naming system has two components: the local part, used 
for username or mailbox identification; and the host part, used for 

global machine identification. 


4.1.1.  VPIM Addresses 


The local part of the address shall be a US-ASCII string uniquely 
identifying a mailbox on a destination system. For voice messaging, 
the local part SHALL be a printable string containing the mailbox ID 
of the originator or recipient. While alpha characters and long 
mailbox identifiers MAY be permitted, short numeric local parts 
SHOULD be used as most voice mail networks rely on numeric mailbox 
identifiers to retain compatibility with the limited 10-digit 
telephone keypad. As a result, some voice messaging systems may only 
be able to handle a numeric local part. The reception of 
alphanumeric local parts on these systems may result in the address 
being mapped to some locally unique (but confusing to the recipient) 
number or, in the worst case the address could be deleted making the 
message unreplyable. Additionally, it may be difficult to create 
messages on these systems with an alphanumeric local part without 
complex key sequences or some form of directory lookup (see 6). The 
use of the Domain Name System should be transparent to the user. It 
is the responsibility of the voice mail machine to lookup the fully- 
qualified domain name (FODN) based on the address entered by the user 
(see 6). 


In the absence of a global directory, specification of the local part 
is expected to conform to international or private telephone 
numbering plans. It is likely that private numbering plans will 
prevail and these are left for local definition. However, it is 
RECOMMENDED that public telephone numbers be noted according to the 
international numbering plan described in [E.164]. The indication 
that the local part is a public telephone number is given by a 
preceding "+" (the "+" would not be entered from a telephone keypad, 
it is added by the system as a flag). Since the primary information 
in the numeric scheme is contained by the digits, other character 


Separators (e.g., "-") may be ignored (i.e., to allow parsing of the 
numeric local mailbox) or may be used to recognize distinct portions 
of the telephone number (e.g., country code). The specification of 


the local part of a VPIM address can be split into the four groups 
described below: 


1) mailbox number 


- for use as a private numbering plan (any number of digits) 
- e.g., 2722@lucent.com 
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2) mailbox number+extension 
- for use as a private numbering plan with extensions 
any number of digits, use of "+" as separator 
- e.g., 2722+111@Lucent.com 


3) «international number 
- for international telephone numbers conforming to E.164 
maximum of 15 digits 
- e.g., +16137637582@vm.nortel.ca 


4) «international numbertextension 
- for international telephone numbers conforming to E.164 
maximum of 15 digits, with an extension (e.g., behind a 
PBX) that has a maximum of 15 digits. 
=- e.g., +17035245550+230@ema.org 


Note that this address format is designed to be compatible with 
current usage within the voice messaging industry. It is not 
compatible with the addressing formats of RFCs 2303-2304. It is 
expected that as telephony services become more widespread on the 
Internet, these addressing formats will converge. 


4.1.2. Special Addresses 


Special addresses to represent the sender are provided for 
compatibility with the conventions of Internet mail. These addresses 
do not use numeric local addresses, both to conform to current 
Internet practice and to avoid conflict with existing numeric 
addressing plans. Two special addresses are RESERVED for use as 
follows: 


postmaster@domain 


By convention, a special mailbox named "postmaster" MUST exist on all 
systems. This address is used for diagnostics and should be checked 
regularly by the system manager. This mailbox is particularly likely 
to receive text messages, which is not normal on a voice-processing 
platform. The specific handling of these messages is an individual 
implementation choice. 


non-mail-user@domain 


If a reply to a message is not possible, such as a telephone- 
answering message, then the special address "non-mail-user" SHOULD be 
used as the originator's address. Any text name such as "Telephone 
Answering", or the telephone number if it is available, is permitted. 
This special address is used as a token to indicate an unreachable 
originator. A conforming implementation MUST NOT permit a reply to an 
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address from "non-mail-user". For compatibility with the installed 
base of mail user agents, implementations MUST reject the message 
when a message addressed to "non-mail-user" is received. The status 
code for such NDN's is 5.1.1 "Mailbox does not exist". 


Example: 
From: Telephone Answering <non-mail-user@mycompany.com> 
4.1.3. Distribution Lists 


There are many ways to handle distribution list (DL) expansions and 
none are 'standard'. A VPIM implementation MAY support DLs. Using a 
simple alias is a behavior closest to what many voice mail systems do 
today and what is to be used with VPIM messages. A couple of 
important features that need special care when DLs are used are: 


Reply to the originator - (Address in the RFC822 "Reply-To:" or 
"From" field) 
Errors to the submitter - (Address in the MAIL FROM field of the 


ESMTP exchange or the "Return-Path:" 
RFC822 field) 


Some proprietary voice messaging protocols include only the recipient 
of the particular copy in the envelope and include no "header fields" 
except date and per-message features. Most voice messaging systems 
do not provide for "Header Information" in their messaging queues and 
only include delivery information. As a result, recipient 
information MAY be in either the "To:" or "Cc:" header fields. If all 
recipients cannot be presented then the recipient header fields 
SHOULD be omitted to indicate that an accurate list of recipients 
(e.g., for use with a reply-all capability) is not known. 


4.2. Message Header Fields 


Internet messages contain a header information block. This header 
block contains information required to identify the sender, the list 
of recipients, the message send time, and other information intended 
for user presentation. Except for specialized gateway and mailing 
list cases, header fields do not indicate delivery options for the 
transport of messages. 


Distribution list processors are noted for modifying or adding to the 
header fields of messages that pass through them.  VPIM systems MUST 
be able to accept and ignore header fields that are not defined here. 


The following header lines are permitted for use with VPIM messages: 
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4.2.1. From 
SEND RULES 


The originator’s fully qualified domain address (a mailbox address 
followed by the fully qualified domain name) MUST be present. 

Systems conforming with this profile SHOULD provide the text personal 
name of the voice message originator in a quoted phrase, if the name 
is available. Text names of corporate or positional mailboxes MAY be 
provided as a simple string. From: [RFC822] 


Example: 
From: "Joe S. User" <12145551212@mycompany.com> 
From: Technical Support <611@serviceprovider.com> 
From: Non-mail-user@myserver.mycompany.com 


Voice mail machines may not be able to support separate attributes 
for the "From:" header fields and the SMTP MAIL FROM, VPIM-conforming 
systems SHOULD set these values to the same address. Use of 
addresses different than those present in the "From:" header field 
address may result in unanticipated behavior. 


RECEIVE RULES 


The user listed in the "From:" field MUST be presented in the voice 
message envelope of the voice messaging system as the originator of 
the message, though the exact presentation is an implementation 
decision (e.g., the mailbox ID or the text name MAY be presented). 
The "From:" address SHOULD be used for replies (see 4.9). 


235242. “IO 
The "To:" field contains the recipient's fully-qualified domain 
address. 
Example: 
To: +12145551213@mycompany.com 
SEND RULES 
There MAY be one or more "To:" fields in any message. Systems SHOULD 


provide a list of recipients only if all recipients are available. 
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Systems, such as gateways from protocols or legacy platforms that do 
not indicate the complete list of recipients, MAY provide a "To:" 
line. Because these systems cannot accurately enumerate all 
recipients in the "To:" headers, recipients SHOULD NOT be enumerated. 


RECEIVE RULES 


Systems conforming to this profile MAY discard the addresses in the 
"To:" fields if they are unable to store the information. This 
would, of course, make a reply-to-all capability impossible. If 
present, the addresses in the "To:" field MAY be used for a reply 
message to all recipients. 


42:3: ICE 
The "Cc:" field contains additional recipients' fully qualified 
domain addresses. Many voice mail systems maintain only sufficient 
envelope information for message delivery and are not capable of 
storing or providing a complete list of additional recipients. 
SEND RULES 
Conforming implementations MAY send "Cc:" lists if all recipients are 
known at the time of origination. If not, systems SHOULD omit the 
"Cc:" fields to indicate that the full list of recipients is unknown 


or otherwise unavailable. The list of disclosed recipients MUST NOT 
include undisclosed recipients (i.e., those sent via a blind copy). 


Example: 

Cc: +12145551213@mycompany.com 
RECEIVE RULES 
Systems conforming to this profile MAY add all the addresses in the 
"Cc:" field to the "To:" field, others MAY discard the addresses in 
the "Cc:" fields. If a list of "Cc:" addresses is present, these 
addresses MAY be used for a reply message to all recipients. 


4.2.4. Date 


The "Date:" field contains the date and time the message was sent by 
the originator. 


SEND RULES 


The sending system MUST report the time the message was sent. The 
time zone MUST be present and SHOULD be represented in a four-digit 
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time zone offset, such as -0500 for North American Eastern Standard 
Time. This MAY be supplemented by a time zone name in parentheses, 
e.g., "-0700 (PDT)". 
Example: 

Date: Wed, 28 Jul 96 10:08:49 -0800 (PST) 
If the VPIM sender is relaying a message from a system that does not 
provide a time stamp, the time of arrival at the gateway system 
SHOULD be used as the date. 
RECEIVE RULES 


Conforming implementations SHOULD be able to convert [RFC822] date 
and time stamps into local time 


4.2.5. Sender 
The "Sender:" field contains the actual address of the originator if 
an agent on behalf of the author indicated in the "From:" field sends 
the message. 
SEND RULES 
This header field MAY be sent by VPIM-conforming systems. 
RECEIVE RULES 
If the address in the "Sender:" field cannot be preserved in the 
recipient’s message queues or in the next-hop protocol from a 
gateway, the field MAY be silently discarded. 


4.2.6. Return-Path 


The "Return-path:" field is added by the final delivering SMTP 
server. If present, it contains the address from the MAIL FROM 


parameter of the ESMTP exchange (see [RFC822]). Any error messages 
resulting from the delivery failure MUST be sent to this address. 
Note that if the "Return-path:" is null ("«»") (e.g., a call answer 


message would have no return path) delivery status notifications MUST 
NOT be sent. 


SEND RULES 


The originating system MUST NOT add this header. 
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RECEIVE RULES 


If the receiving system is incapable of storing the return path (or 
MAIL FROM) to be used for subsequent delivery errors (i.e., it is a 
gateway to a legacy system or protocol), the receiving system must 
otherwise ensure that further delivery errors don't happen. Systems 
that do not support the return path MUST ensure that at the time the 
message is acknowledged (i.e., when a DSN would be sent), the message 
is delivered to the recipient's ultimate mailbox.  Non-Delivery 
notifications SHOULD NOT be sent after that final delivery. 


4.2.7. Message-id 


The "Message-Id:" field contains a globally unique per-message 
identifier. 


SEND RULES 


A globally unique message-id MUST be generated for each message sent 
from a VPIM-conforming implementation. 


Example: 
Message-Id: <12345678@mycompany.com> 

RECEIVE RULES 
When provided in the original message, it MUST be used when sending a 
MDN. This identifier MAY be used for tracking and auditing. From 
[RFC822] 

4.2.8. Reply-To 
If present, the "Reply-To:" header provides a preferred address to 
which reply messages should be sent (see 4.9). Typically, voice mail 
systems can only support one originator of a message so it is likely 
that this field will be ignored by the receiving system. From: 
[RFC822] 
SEND RULES 
A conforming system SHOULD NOT send a "Reply-To:" header. 
RECEIVE RULES 
If a "Reply-To:" field is present, a reply-to-sender message MAY be 


sent to the address specified (that is, in lieu of the address in the 
"From:" field). If the receiving system (e.g., multi-protocol 
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gateway) only supports one address for the originator, then the 
address in the "From:" field MUST be used and the "Reply-To:" field 
MAY be silently discarded. 


4.2.9. Received 


The "Received:" field contains trace information added to the 
beginning of a RFC822 message by MTAs. This is the only field that 
may be added by an MTA. Information in this header is useful for 
debugging when using an US-ASCII message reader or a header-parsing 
tool. From: [RFC822] 


SEND RULES 


A VPIM-conforming system MUST add a "Received:" field. When acting 
as a gateway, information about the system from which the message was 
received SHOULD be included. 


RECEIVE RULES 


A VPIM-conforming system MUST NOT remove any "Received:" fields when 
relaying messages to other MTAs or gateways. These header fields MAY 
be ignored or deleted when the message is received at the final 
destination. 


4.2.10. MIME Version 


The "MIME-Version:" field MUST be present to indicate that the 
message conforms to [MIME1-5]. Systems conforming with this 
specification SHOULD include a comment with the words "(Voice 2.0)". 
[VPIM1] defines an earlier version of this profile and uses the token 
(Voice 1.0). Example: 


MIME-Version: 1.0 (Voice 2.0) 


This identifier is intended for information only and SHOULD NOT be 
used to semantically identify the message as being a VPIM message. 
Instead, the presence of the multipart/voice-message content type 
defined in section 18.2 SHOULD be used if identification is 
necessary. 


4.2.11. Content-Type 


The "Content-Type:" header MUST be present to declare the type of 
content enclosed in the message. The typical top-level content ina 
VPIM Message SHOULD be Multipart/Voice-Message. The allowable 
contents are detailed starting in section 4.4 of this document. 
From: [MIME2] 
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4.2.12.  Content-Transfer-Encoding 


Because Internet mail was initially specified to carry only 7-bit 
US-ASCII text, it may be necessary to encode voice and fax data into 


a representation suitable for that environment. The "Content- 
Transfer-Encoding:" header describes this transformation if it is 
needed. 

SEND RULES 


An implementation in conformance with this profile SHOULD send audio 
and/or facsimile data in "Binary" form when binary message transport 
is available (see section 5). When binary transport is not 
available, implementations MUST encode the audio and/or facsimile 
data as "Base64". 


RECEIVE RULES 


Conforming implementations MUST recognize and decode the standard 
encodings, "Binary" (when binary support is available), "7bit, 
"8bit", "Base64" and "Quoted-Printable" per [MIME1]. The detection 
and decoding of "Quoted-Printable", "7bit", and "8bit" MUST be 
supported in order to meet MIME requirements and to preserve 
interoperability with the fullest range of possible devices. 


4.2.13. Sensitivity 
The "Sensitivity:" field, if present, indicates the requested privacy 


level. If no privacy is requested, this field is omitted. The 
header definition is as follows: 


Sensitivity :- "Sensitivity" ":" Sensitivity-value 
Sensitivity-value := "Personal" / "Private" / "Company-Confidential" 
SEND RULES 


A VPIM-conforming implementation MAY include this header to indicate 
the sensitivity of a message. If a user marks a message "Private", a 
conforming implementation MUST send only the "Private" sensitivity 
level. There are no VPIM-specific semantics defined for the values 
"Personal" or "Company-Confidential". A conforming implementation 
SHOULD NOT send the values "Personal" or "Company-Confidential". If 
the message is of "Normal" sensitivity, this field SHOULD be omitted. 
From: [X.400] 
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RECEIVE RULES 


If a "Sensitivity:" field with a value of "Private" is present in the 
message, a conforming system MUST prohibit the recipient from 
forwarding this message to any other user. A conforming system, 
however, SHOULD allow the responder to reply to a sensitive message, 
but SHOULD NOT include the original message content. The responder 
MAY set the sensitivity of the reply message. 


A receiving system MAY ignore sensitivity values of "Personal" and 
"Company Confidential". 


If the receiving system does not support privacy and the sensitivity 
is "Private", a negative delivery status notification MUST be sent to 
the originator with the appropriate status code (5.6.0) "Other or 
undefined protocol status" indicating that privacy could not be 
assured. The message contents SHOULD be returned to the sender to 
allow for a voice context with the notification. A non-delivery 
notification to a private message SHOULD NOT be tagged private since 
it will be sent to the originator. From: [X.400] 


A message with no privacy explicitly noted (i.e., no header) or with 
"Normal" sensitivity has no special treatment. 


4.2.14. Importance 


Indicates the requested importance to be given by the receiving 
System. If no special importance is requested, this header MAY be 
omitted and the value of the absent header assumed to be "normal". 
From: [X.400] 


Importance := "Importance" ":" importance-value 
Importance-value :- "low" / "normal" / "high" 
SEND RULES 


Conforming implementations MAY include this header to indicate the 
importance of a message. 


RECEIVE RULES 


If the receiving system does not support "Importance:", the attribute 
MAY be silently dropped. 
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4.2.15. Subject 


The "Subject:" field is often provided by email systems but is not 
widely supported on voice mail platforms. From: [RFC822] 


SEND RULES 


For compatibility with text-based mailbox interfaces, a text subject 
field SHOULD be generated by a conforming implementation. It is 
RECOMMENDED that voice-messaging systems that do not support any text 
user interfaces (e.g., access only by a telephone) insert a generic 
subject header of "VPIM Message" or "Voice Message" for the benefit 
of GUI-enabled recipients. 


RECEIVE RULES 
It is anticipated that many voice-only systems will be incapable of 
storing the subject line. The subject MAY be discarded by a 
receiving system. 

4.3. MIME Audio Content Descriptions 


4.3.1.  Content-Description 


This field MAY be present to facilitate the text identification of 
these body parts in simple email readers. Any values may be used. 


Example: 
Content-Description: Big Telco Voice Message 
SEND RULES 


This field MAY be added to a voice body part to offer a freeform 
description of the voice content. It is useful to incorporate the 
values for Content-Disposition with additional descriptions. For 
example, this can be used to indicate product name or transcoding 
records. 


RECEIVE RULES 


This field MAY be displayed to the recipient. However, since it is 
only informative it MAY be ignored. 
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4.3.2. Content-Disposition 


This field MUST be present to allow the parsable identification of 


body parts within a VPIM voice message. This is especially useful 
if, as is typical, more than one Audio/* body occurs within a single 
level (e.g., Multipart/Voice-Message). Since a VPIM voice message is 


intended to be automatically played in the order in which the audio 
contents occur, the audio contents MUST always be of disposition 
inline. However, it is still useful to include a filename value, so 
this SHOULD be present if this information is available. From: 
[DISP] 


SEND RULES 


In order to distinguish between the various types of audio contents 
in a VPIM voice message a new disposition parameter "voice" is 
defined with IANA (see section 18.1) with the parameter values below 
to be used as appropriate: 


Audio-Type := "voice" "=" Audio-type-value 


Audio-type-value := "Voice-Message" / "Voice-Message-Notification" / 
"Originator-Spoken-Name" /"Recipient-Spoken-Name" /"Spoken-Subject" 


Voice-Message - the primary voice message, 
Voice-Message-Notification - a spoken delivery notification 
or spoken disposition notification, 
Originator-Spoken-Name - the spoken name of the originator, 
Recipient-Spoken-Name - the spoken name of the recipient(s) if 
available to the originator 
Spoken-Subject- the spoken subject of the message, typically 
Spoken by the originator 


Note that there SHOULD only be one instance of each of these types of 
audio contents per message level. Additional instances of a given 
type (i.e., parameter value) MAY occur within an attached forwarded 
or reply voice message. If there are multiple recipients for a given 
message, recipient-spoken-name MUST NOT be used. 


RECEIVE RULES 


Implementations SHOULD use this header. However, those that do not 
understand the "voice" parameter (or the "Content-Disposition:" 
header) can safely ignore it, and will present the audio body parts 
in order (but will not be able to distinguish between them). If more 
than one instance of the "voice" parameter type value is encountered 
at one level (e.g., multiple 'Voice-Message' tagged contents) then 
they SHOULD be presented together. 
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4.3.3.  Content-Duration 


The "Content-Duration:" header provides an indication of the audio 
length in seconds of the segment. 


Example: 
Content-Duration: 33 
SEND RULES 


This field MAY be present to allow the specification of the length of 
the audio body part in seconds. 


RECEIVE RULES 


The use of this field on reception is a local implementation issue. 
From: [DUR] 


4.3.4.  Content-Language: 


This field MAY be present to allow the specification of the spoken 
language of the audio body part. The encoding is defined in [LANG]. 


Example for UK English: 
Content-Language: en-UK 

SEND RULES 
A sending system MAY add this field to indicate the language of the 
voice. The determination of this (e.g., automated or user-selected) 
is a local implementation issue. 
RECEIVE RULES 
The use of this field on reception is a local implementation issue. 
It MAY be used as a hint to the recipient (e.g., end-user or an 
automated translation process) as to the language of the voice 
message. 

4.4. Voice Message Content Types 
The content types described in this section are identified for use 
within the Multipart/Voice-Message content. This content is referred 


to as a "VPIM message" in this document and is the fundamental part 
of a "VPIM message". 
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Only the contents profiled can be sent within a VPIM voice message 
construct (i.e., the Multipart/Voice-Message content type) to form a 
simple or a more complex structure (several examples are given in 
Appendix B). The presence of other contents within a VPIM voice 
message is not permitted. In the absence of a bilateral agreement, 
conforming implementations MUST NOT create a message containing 
prohibited contents. In the spirit of liberal acceptance, a 
conforming implementation MAY accept and render prohibited content. 
Systems unable to accept or render prohibited contents MAY discard 
the prohibited contents as necessary to deliver the acceptable 
content. When multiple contents are present within the 
Multipart/Voice-Message, they SHOULD be presented to the user in the 
order that they appear in the message. 


Some deployed implementations based on a common interpretation of the 
original VPIM v2 specification reject messages with prohibited 
content rather than discard the unsupported contents. For 
interoperability with these systems, it is especially important that 
prohibited contents not be sent within a Multipart/Voice-Message. 


4.4.1. Multipart/Voice-Message 


This MIME multipart structure provides a mechanism for packaging a 
voice message into one container that is tagged as VPIM v2 
conforming. The sub-type is identical in semantics and syntax to 
multipart/mixed, as defined in [MIME2]. As such, it may be safely 
interpreted as a multipart/mixed by systems that do not understand 
the sub-type (only the identification as a voice message would be 
lost). 


In addition to the MIME required boundary parameter, a version 
parameter is also required for this sub-type. This is to distinguish 
this refinement of the sub-type from the previous definition in 
[VPIM1]. The value of the version parameter is "2.0" if the content 
conforms to the requirements of this specification. Should there be 
further revisions of this content type, there MUST be backwards 
compatibility (i.e., systems implementing version n can read version 
2, and systems implementing version 2 can read version 2 contents 
within a version n). 


SEND RULES 


The Multipart/Voice-Message content-type MUST only contain the 
profiled media and content types specified in this section (i.e., 
Audio/*, Image/*, and Message/RFC822). The most common will be: 
spoken name, spoken subject, the message itself, and an attached fax. 
Forwarded messages are created by simply using the Message/RFC822 
construct. 
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Conformant implementations MUST use Multipart/Voice-Message in a VPIM 
message. In most cases, this Multipart/Voice-Message Content-Type 
will be the top level but may be included within a Message/RFC822 if 
the message is forwarded or within a multipart/mixed when more than 
one message is being forwarded. 


RECEIVE RULES 


Conformant implementations MUST recognize the Multipart/Voice-Message 
content (whether it is a top-level content or contained ina 
Multipart/Mixed) and MUST be able to separate the contents (e.g., 
spoken name or spoken subject). 


The semantic of Multipart/Voice-Message (defined in section 18.2) is 
identical to Multipart/Mixed and may be interpreted as that by 
systems that do not recognize this content-type. 


4.4.2. Message/RFC822 


SEND RULES 


MIME requires support of the Message/RFC822 message encapsulation 
body part. This body part SHOULD be used within a Multipart/Voice- 
Message to forward complete messages (see 4.8) or to reply with 
original content (see 4.9). From: [MIME2] 


RECEIVE RULES 


The receiving system MUST accept this format and SHOULD treat this 
attachment as a forwarded message. The receiving system MAY flatten 
the forwarding structure (i.e., remove this construct to leave 
multiple voice contents or even concatenate the voice contents to fit 
in a recipient’s mailbox), if necessary. 


4.4.3. | Audio/32KADPCM 


SEND RULES 


An implementation conforming to this profile MUST send Audio/32KADPCM 
by default for voice [ADPCM]. This encoding is a moderately- 
compressed encoding with a data rate of 32 kbits/second using 
moderate processing resources. Typically, this body contains several 
minutes of message content; however, if used for spoken name or 
subject the content is expected to be considerably shorter (i.e., 
about 5 and 10 seconds respectively). 
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RECEIVE RULES 


Receivers MUST be able to accept and decode Audio/32KADPCM. If an 
implementation can only handle one voice body, then multiple voice 
bodies (if present) SHOULD be concatenated, and MUST NOT be 
discarded. If concatenated, the contents SHOULD be in the same order 
they appeared in the multipart. 


4.4.4.  Image/TIFF 


A common image encoding for facsimile, known as TIFF-F, is a 
derivative of the Tag Image File Format (TIFF) and is described in 
several documents. For the purposes of VPIM, the F Profile of TIFF 
for Facsimile (TIFF-F) is defined in [TIFF-F], and the Image/TIFF 
MIME content-type is defined in [TIFFREG]. While there are several 
formats of TIFF, only TIFF-F is profiled for use within 
Multipart/Voice-Message. Further, since the TIFF-F file format is 
used in a store-and-forward mode with VPIM, the image MUST be encoded 
so that there is only one image strip per facsimile page. 


SEND RULES 


All VPIM implementations that support facsimile MUST generate TIFF-F 
compatible facsimile contents in the Image/TIFF subtype using the 
application-faxbw encoding by default. If the VPIM message is a 
voice- annotated fax, the implementation SHOULD send this fax content 
in Multipart/Voice-Message. If the message is a simple fax, an 
implementation MAY send it without using the Multipart/Voice-Message 
to be more compatible with fax-only (RFC 2305) implementations. 


While any valid MIME body header MAY be used (e.g., Content- 
Disposition to indicate the filename), none are specified to have 
special semantics for VPIM and MAY be ignored. Note that the 
content-type parameter application-faxbw MUST be included in outbound 
messages. 


RECEIVE RULES 


Not all VPIM systems support fax, but all SHOULD accept it within the 
multipart/voice-message. Within a Multipart/Voice-Message, a 
receiving system that cannot render fax content SHOULD accept the 
voice content of a VPIM message and discard the fax content. Outside 
a Multipart/Voice-Message, a recipient system MAY reject (with 
appropriate NDN) the entire message if it cannot store or is not 
capable of rendering a message with fax attachments.  VPIM conforming 
Systems MAY support fax outside of (or without) the Multipart/Voice- 
Message. 
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Some deployed implementations based on a common interpretation of the 
original VPIM V2 specification reject messages with fax content 
within the Multipart/Voice-Message rather than discard the 
unsupported contents. These systems will return the message to the 
sender with an NDN indicating lack of support for fax. 


4.5. Other MIME Contents 


The following MIME contents (with the exception of multipart/mixed in 
section 4.5.1) MAY be included within a multipart/voice message. 
Other contents MUST NOT be included. Their handling is a local 
implementation issue. Multipart/mixed is included to promote 
interoperability with a wider range of systems and also to allow the 
creation of more complex multimedia messages (with a VPIM message as 
one part). 


4.5.1. Multipart/Mixed 


This common MIME content-type allows the enclosing of several body 
parts in a single message. 


SEND RULES 


A VPIM voice message (i.e., multipart/voice-message) MAY be included 
within a message with a Multipart/Mixed top-level content type. 
Typically, this would only be used when mixing non-voice and non-fax 
contents with a voice message. 


RECEIVE RULES 


Such a message is not itself a VPIM message and the handling of such 
a construct is outside the scope of the VPIM profile. However, an 
the spirit of liberal acceptance, a conforming implementation MUST 
accept and render a VPIM voice message contained ina 

Multipart /Mixed. 


4.5.2. Text/Directory 
SEND RULES 
This content was profiled in the original specification of VPIM v2 as 
a means of transporting contact information from the sender to the 
recipient. This usage did not find widespread adoption and is no 


longer a feature of VPIM V2. Conforming implementations SHOULD NOT 
send the Text/Directory content type. 
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RECEIVE RULES 


For compatibility with an earlier specification of VPIM v2, the 
Text/Directory content type MUST be accepted by a conforming 
implementation, but need not be stored, processed, or rendered to the 
recipient. 


4.5.3. Proprietary Voice or Fax Formats 


Use of any other encoding except the required codecs reduces 
interoperability in the absence of explicit knowledge about the 
capabilities of the recipient. A conforming implementation SHOULD 
NOT use any other encoding unless a unique identifier is registered 
with the IANA prior to use (see [MIME4]). The voice encodings SHOULD 
be registered as subtypes of Audio. The fax encodings SHOULD be 
registered as subtypes of Image. 


SEND RULES 


Proprietary voice encoding formats or other standard formats SHOULD 
NOT be sent under this profile unless the sender has a reasonable 
expectation that the recipient will accept the encoding. In 
practice, this requires explicit per-destination configuration 
information maintained either in a directory, personal address book, 
or gateway configuration tables. 


RECEIVE RULES 


Systems MAY accept other Audio/* or Image/* content types if they can 
decode them. Systems which receive Audio/* or Image/* content types 
which they are unable to deposit or unable to render MUST return the 
message (and SHOULD include the original content) to the originator 
with an NDN indicating media not supported. 


4.5.4. Text/Plain 


MIME requires support of the basic Text/Plain content type (with the 
US-ASCII character set). This content type has limited applicability 
within the voice-messaging environment. However, because VPIM is a 
MIME profile, MIME requirements SHOULD be met. 


SEND RULES 
Conforming VPIM implementations SHOULD NOT send the Text/Plain 


content-type. Implementations MAY send the Text/Plain content-type 
outside the Multipart/Voice-Message. 
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RECEIVE RULES 


Within a Multipart/Voice-Message, the Text/Plain content-type MAY be 
dropped from the message, if necessary, to deliver the audio/fax 
components. The recipient SHOULD NOT reject the entire message if 
the text component cannot be accepted or rendered. 


Outside a Multipart/Voice-Message, conforming implementations MUST 
accept Text/Plain; however, specific handling is left as an 
implementation decision. From: [MIME2] 


Some deployed implementations based on a common interpretation of the 
original VPIM V2 specification reject messages with any text content 
rather than discard the unsupported contents. These systems will 
return the message to the sender with an NDN indicating lack of 
support for text. 


4.6. Delivery Status Notification (DSN) 


A DSN is a notification of delivery (positive DSN), non-delivery 


(negative DSN), or temporary delivery delay (delayed DSN). The top- 
level content-type of a DSN is Multipart/Report, which is defined in 
[REPORT]. The content-type which distinguishes DSN’s from other 
types of notifications is Message/Delivery-Status, which is defined 
in [DSN]. 

SEND RULES 


A VPIM-compliant implementation MUST be able to send DSN’s that 


conform to [REPORT] and [DSN]. Unless requested otherwise, a non- 
delivery DSN MUST be sent when any form of non-delivery of a message 
occurs. 


A VPIM-compliant implementation SHOULD provide a spoken delivery 
status in the "human-readable" body part of the DSN, but MAY provide 
a textual status. 


RECEIVE RULES 


A VPIM-compliant implementation MUST be able to receive DSN’s that 
conform to [REPORT] and [DSN]. 


A VPIM-compliant implementation MUST be able to receive a DSN whose 
"human-readable" body part contains a spoken delivery status phrase 
or a textual description. Though subsequent use of the phrase or 
text is a local implementation issue, the intent of the DSN MUST be 
presented to the end user. 
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4.7. Message Disposition Notification (MDN) 


An MDN is a notification indicating what happens to a message after 
it is deposited in the recipient’s mailbox. An MDN can be positive 
(message was read/played/rendered/etc.) or negative (message was 
deleted before recipient could see it, etc.). The top-level 
content-type of a MDN is Multipart/Report, which is defined in 
[REPORT]. The content-type which distinguishes MDN’s from other 
types of notifications is Message/Disposition-Notification, which is 
defined in [MDN]. 


SEND RULES 


A VPIM-compliant implementation SHOULD support the ability to request 
MDNs. This is done via the use of the "Disposition-Notification-To:" 
header field as defined in [MDN]. 


A VPIM-compliant implementation SHOULD support the ability to send 
MDNs, but these MDNs MUST conform to [REPORT] and [MDN]. 


When sending an MDN, a VPIM-compliant implementation SHOULD provide a 
spoken message disposition in the "human-readable" body part of the 
MDN, but MAY provide a textual status. 


RECEIVE RULES 


A VPIM-compliant implementation SHOULD respond to an MDN request with 
an MDN response. 


A VPIM-compliant implementation MUST be able to receive MDNs that 
conform to [REPORT] and [MDN], if it is capable of requesting MDNs. 
If a VPIM-compliant implementation is capable of receiving MDNs, it 
MUST be able to receive a MDN whose "human-readable" body part 
contains a spoken message disposition phrase or a textual disposition 
description. Though subsequent use of the phrase or text is a local 
implementation issue, the intent of the MDN MUST be presented to the 
end user. 


4.8. Forwarded Messages 


VPIM v2 explicitly supports the forwarding of voice and fax content 
with voice or fax annotation. However, only the two constructs 
described below are acceptable in a VPIM message. Since only the 
first (i.e., Message/RFC822) can be recognized as a forwarded message 
(or even multiple forwarded messages), it is RECOMMENDED that this 
construct be used whenever possible. 
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Forwarded VPIM messages SHOULD be sent as a Multipart/Voice-Message 
with the entire original message enclosed in a Message/RFC822 
content-type and the annotation as a separate Audio/* or Image/* body 
part. If the RFC822 header fields are not available for the 
forwarded content, simulated header fields with available information 
SHOULD be constructed to indicate the original sending timestamp, and 
the original sender as indicated in the "From:" field. Note that at 
least one of "From:", "Subject:", or "Date:" MUST be present. As 
well, the Message/RFC822 content MUST include at least the "MIME- 
Version:", and "Content-Type:" header fields. From: [MIME2] 


In the event that forwarding information is lost, the entire audio 
content MAY be sent as a single Audio/* segment without including any 
forwarding semantics. An example of this loss is an AMIS message 
being forwarded through an AMIS-to-VPIM gateway. 


4.9. Reply Messages 
VPIM v2 explicitly supports replying to received messages. 


Support of multiple originator header fields in a reply message is 
often not possible on voice messaging systems, so it may be necessary 
to choose only one when gatewaying a VPIM message to another voice 
message system. However, implementers should note that this may make 
it impossible to send DSN’s, MDN’s, and replies to their proper 
destinations. 


In some cases, replying to a message is not possible, such as with a 
message created by telephone answering (i.e., classic voice mail). 

In this case, the From field SHOULD contain the special address non- 
mail-user@domain (see 4.1.2). The recipient’s VPIM system SHOULD NOT 
offer the option to reply to this kind of message (unless an 
outcalling feature is offered - which is out of scope for VPIM). 


5. Message Transport Protocol 


Messages are transported between voice mail machines using the 
Internet Extended Simple Mail Transfer Protocol (ESMTP). All 
information required for proper delivery of the message is included 
in the ESMTP dialog. This information, including the sender and 
recipient addresses, is commonly referred to as the message 
"envelope". This information is equivalent to the message control 
block in many analog voice messaging protocols. 


ESMTP is a general-purpose messaging protocol, designed both to send 
mail and to allow terminal console messaging. Simple Mail Transport 
Protocol (SMTP) was originally created for the exchange of US-ASCII 
7-bit text messages. Binary and 8-bit text messages have 
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traditionally been transported by encoding the messages into a 7-bit 
text-like form. [ESMTP] formalized an extension mechanism for SMTP, 
and subsequent RFCs have defined 8-bit text networking, command 
streaming, binary networking, and extensions to permit the 
declaration of message size for the efficient transmission of large 
messages such as multi-minute voice mail. 


The following sections list ESMTP commands, keywords, and parameters 
that are required and those that are optional for conformance to this 


profile. 


1. Base SMTP Protocol 


A conforming system MUST implement all mandatory SMTP and ESMTP 
commands. Any defined optional command or parameter MAY be 
supported. 


.2. SMTP Service Extensions 


VPIM utilizes a number of SMTP Service Extensions to provide full- 
featured voice messaging service. The following extensions are 
profiled for use with VPIM: 


.2.1. DSN Extension 


The DSN extension defines a mechanism which allows an SMTP client to 
specify (a) DSN's should be generated under certain conditions, (b) 
whether such DSN's should return the contents of the message, and (c) 
additional information, to be returned with a DSN, that allows the 
sender to identify both the recipient(s) for which the DSN was 
issued, and the transaction in which the original message was sent. 


The DSN extension MUST be supported by VPIM conforming 
implementations. 


In addition, beyond the requirements of [DRPT], conforming 
implementations MUST support NOTIFY parameter on the RCPT command to 
allow indication of when the originator requests a notification. The 
RET parameter SHOULD be supported to return the original message with 
the notification. Parameters ORCPT and ENVID MAY also be supported. 
From: [DRPT] 


.2.2. SIZE Extension 


The SIZE extension defines a mechanism whereby an SMTP client and 
Server may interact to give the server an opportunity to decline to 
accept a message (perhaps temporarily) based on the client's estimate 
of the message size. From: [SIZE] 
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The SIZE extension MUST be supported by VPIM-compliant 
implementations. 


5.2.3. ENHANCEDSTATUSCODES Extension 


The ENHANCEDSTATUSCODES extension defines a mechanism whereby an SMTP 
server augments its responses with the enhanced mail system status 
codes defined in [CODES]. These codes can then be used to provide 
more informative explanations of error conditions. From: [STATUS] 


The ENHANCEDSTATUSCODES extension SHOULD be supported by VPIM- 
compliant implementations. 


5.2.4.  PIPELINING Extension 


The PIPELINING extension defines a mechanism whereby an SMTP server 
can indicate the extent of its ability to accept multiple commands in 
a single TCP send operation. Using a single TCP send operation for 
multiple commands can improve SMTP performance significantly. From 
[PIPE] 


The PIPELINING extension SHOULD be supported by VPIM-compliant 
implementations. 


5.2.5.  CHUNKING Extension 


The CHUNKING extension defines a mechanism that enables an SMTP 
client and server to negotiate the use of the message data transfer 
command "BDAT" (in alternative to the DATA command) for efficiently 
sending large MIME messages. From: [BINARY] 


The CHUNKING extension MAY be supported by VPIM-compliant 
implementations. 


5.2.6.  BINARYMIME Extension 
The BINARYMIME extension defines a mechanism that enables an SMTP 
client and server to negotiate the transfer of unencoded binary 
message data utilizing the BDAT command. From: [BINARY] 
The BINARYMIME extension MAY be supported by VPIM-compliant 


implementations. Note that [BINARY] specifies that if BINARYMIME is 
to be supported, then CHUNKING has to be supported by definition. 
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5.3. ESMTP - SMTP Downgrading 


The SMTP extensions suggested or required for conformance to VPIM 
fall into two categories. The first category includes features that 
increase the efficiency of the transport system such as SIZE, 
BINARYMIME, and PIPELINING. In the event of a downgrade to a less- 
functional transport system, these features can be dropped with no 
functional change to the sender or recipient. 


The second category of features is transport extensions in support of 
new functions. DSN and ENHANCEDSTATUSCODES provide essential 
improvements in the handling of delivery status notifications to 
bring email to the level of reliability expected of Voice Mail. To 
ensure a consistent level of service across an intranet or the global 
Internet, it is essential that VPIM-conforming ESMTP support the DSN 
extension at all hops between a VPIM originating system and the 
recipient system. In the situation where a "downgrade" is 
unavoidable a relay hop may be forced (by the next hop) to forward a 
VPIM message without the ESMTP request for delivery status 
notification. It is RECOMMENDED that the downgrading system should 
continue to attempt to deliver the message, but MUST send an 
appropriate delivery status notification to the originator, e.g., the 
message left an ESMTP host and was sent relayed to a non-DSN-aware 
destination, and this may be the last DSN received. 


6. Directory Address Resolution 


It is the responsibility of a VPIM system to provide the fully- 
qualified domain name (FQDN) of the recipient based on the address 
entered by the user (if the entered address is not already a FQDN). 
This would typically be an issue on systems that offer only a 
telephone user interface. The mapping of the dialed target number to 
a routable FODN address, allowing delivery to the destination system, 
can be accomplished through implementation-specific means. 


To facilitate a local cache, an implementation may wish to populate 
local directories with the first and last names, as well as the 
senders' spoken name information extracted from received messages. 
Addresses or names parsed from the header fields of VPIM messages MAY 
be used to populate directories. 


7. Management Protocols 
The Internet protocols provide a mechanism for the management of 
messaging systems, from the management of the physical network 


through the management of the message queues. SNMP SHOULD be 
supported on a VPIM-conforming machine. 
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7.1. Network Management 


The digital interface to the VM and the TCP/IP protocols MAY be 
managed. MIB II MAY be implemented to provide basic statistics and 
reporting of TCP and IP protocol performance [MIB II]. 


8. Conformance Requirements 


VPIM is a messaging application that will be supported in several 
environments and be supported on differing devices. These 
environments include traditional voice processing systems, desktop 
voice messaging systems, store-and-forward relays, and protocol 
translation gateways. 


In order to accommodate all environments, this document defines two 
areas of conformance: transport and content. 


Transport-conformant systems will pass VPIM messages in a store-and- 
forward manner with assured delivery notifications and without the 


loss of information. It is expected that most store-and-forward 
Internet mail-based messaging systems will be VPIM transport- 
conformant. 


Content-conformant systems will generate and interpret VPIM messages. 
Conformance in the generation of VPIM messages indicates that the 
restrictions of this profile are honored. Only contents specified in 
this profile or extensions agreed to by bilateral agreement may be 
sent. Conformance in the interpretation of VPIM messages indicates 
that all VPIM content types and constructs can be received; that all 
mandatory VPIM content types can be decoded and presented to the 
recipient in an appropriate manner; and that any unrenderable 
contents result in the appropriate notification. 


A summary of the conformance requirements is contained in Appendix A. 


VPIM end systems are expected to be both transport- and content- 
conformant. Voice messaging systems and protocol conversion gateways 
are considered end systems. 


Relay systems are expected to be transport-conformant in order to 
receive and send conforming messages. However, they must also create 
VPIM-conforming delivery status notifications in the event of 
delivery problems. 


Desktop Email clients that support VPIM are expected to be content- 
conformant. Desktop email clients use various protocols and API's 
for exchanging messages with the local message store and message 
transport system. While these clients may benefit from VPIM 
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transport capabilities, specific client-server requirements are out- 
of-scope for this document. 


9. Security Considerations 
9.1. General Directive 
This document is a profile of existing Internet mail protocols. To 


maintain interoperability with Internet mail, any security to be 
provided should be part of the Internet security infrastructure, 
rather than a new mechanism or some other mechanism outside of the 
Internet infrastructure. 


9.2. Threats and Problems 
Both Internet mail and voice messaging have their own set of threats 


and countermeasures. As such, this specification does not create any 
security issues not already existing in the profiled Internet mail 


and voice mail protocols themselves. This section attends only to 
the set of additional threats that ensue from integrating the two 
services. 


9.2.1. Spoofed sender 


The actual sender of the voice message might not be the same as that 
specified in the "Sender:" or "From:" message header fields or the 
MAIL FROM address from the SMTP envelope. In a tightly constrained 
environment, sufficient physical and software controls may be able to 
ensure prevention of this problem. In addition, the recognition of 
the sender’s voice may provide confidence of the sender’s identity 
irrespective of that specified in "Sender:" or "From:". It should be 
recognized that SMTP implementations do not provide inherent 
authentication of the senders of messages, nor are sites under 
obligation to provide such authentication. 


9.2.2. Unsolicited voice mail 


Assigning an Internet mail address to a voice mailbox opens the 
possibility of receiving unsolicited messages (either text or voice 
mail). Traditionally, voice mail systems operated in closed 
environments and were not susceptible to unknown senders. Voice mail 
users have a higher expectation of mailbox privacy and may consider 
such messages as a security breach. Many Internet mail systems are 
choosing to block all messages from unknown sources in an attempt to 
curb this problem. 
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9.2.3. Message disclosure 


Users of voice messaging systems have an expectation of a level of 

message privacy that is higher than the level provided by Internet 

mail without security enhancements. This expectation of privacy by 
users SHOULD be preserved as much as possible. 


9.3. Security Techniques 


Sufficient physical and software control may be acceptable in 
constrained environments. Further, the profile specified in this 
document does not in any way preclude the use of any Internet object 
or channel security protocol to encrypt, authenticate, or non- 
repudiate the messages. 
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12. Appendix A - VPIM Requirements Summary 


The following table summarizes the profile of VPIM version 2 detailed 
in this document. Since in many cases it is not possible to simplify 
the qualifications for supporting each feature this appendix is 
informative. The reader is recommended to read the complete 
explanation of each feature in the referenced section. The text in 
the previous sections shall be deemed authoritative if any item in 
this table is ambiguous. 


The conformance table is separated into various columns: 


Feature - name of protocol feature (note that the indenting 
indicates a hierarchy of conformance, i.e., the 
conformance of a lower feature is only relevant if there 
is conformance to the higher feature) 


Section - reference section in main text of this document 


Area - conformance area to which each feature applies: 
C - content 
T - transport 


Status - whether the feature is mandatory, optional, or prohibited. 
The key words used in this table are to be interpreted as described 
in [REO], though the following list gives a quick overview of the 
different degrees of feature conformance: 


Must - mandatory 
Should - required in the absence of a compelling 
need to omit. 
May - optional 
Should not - prohibited in the absence of a compelling 
need. 
Must not - prohibited 
Footnote - special comment about conformance for a particular feature 
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VPIM version 2 Conformance 


A A ] 
H F 
| LLLI fats 
| | | |s| [ujulo 
| | | [al leiste 
| la|w|o| [p|v|n 
| [R|u|u|m| | lo 
E|S|LJ|A|N|N|t 
| BESEEHE 
FEATURE [SECTION | | | | |T|T[e 
ic zc D M I P COE Memeo esd Esse esses ps 
| GS am Fae Ae Ue 
Message Addressing Formats: | RED EEN Hae IP 
Use DNS host names [4.1 [clx | [ub | 
Use only numbers in mailbox IDs 2-1 E x 
Numbers in mailbox IDs follow E.164 m M x | | | 
Use alpha-numeric mailbox IDs [4.1.1 Ic] | |x| | 
Support of postmaster@domain |4.1.2 [cixl | | | 
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FEATURE 


Message Content Types: 
Sending outbound messages 
Multipart/Voice-Message 
Message/RFC822 
Audio/32KADPCM 
Content-Description 
Content-Disposition 
Content-Duration 
Content-Language 
Image/TIFF; application=faxbw 
Text/Directory 
Text /plain 
Audio/* or Image/* 
Other contents 
Multipart/Mixed 
Text /plain 
Multipart/Report 
human-readable part is voice 
human-readable part is text 
Message/Delivery-Status 
Message/Disposition-Notification 
Other contents 


(other encodings) 


Receiving in inbound messages 
Multipart/Voice-Message 
Message/RFC822 
Audio/32KADPCM 
Content-Description 
Content-Disposition 
Content-Duration 
Content-Language 
Image/TIFF; application=faxbw 
Text/Directory 
Text/plain 
Audio/* or Image/* 
Other contents 
Multipart/Mixed 


(other encodings) 
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4.5.3 
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FEATURE 


Text/plain 

Multipart/Report 
human-readable part is voice 
human-readable part is text 
Message/Delivery-Status 
Message/Disposition-Notification 

Other contents 


ds ds ds ds ds aS A 


Forwarded Messages 
use Message/RFC822 construct 
simulate headers if none available 


A A 


Reply Messages 
send to Reply-To, else From address 
send to non-mail-user 


BPs 


Notifications 
use Multipart/Report format 
always send error on non-delivery 
send error messages to return-path 


BPs 


Message Transport Protocol: 
Base ESMTP Commands 

HELO 

MAIL FROM 

RCPT TO 

DATA 

TURN 

QUIT 

RSET 

VRFY 

EHLO 

BDAT 


O1 O1 O1 O1 O1 OI O1 A 
hh pp 
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Welle a UA 
| It df al e 
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| PETTY] 
ESMTP Keywords & Parameters | | | | | | | 
DSN [asd [rixs ER ID UN 
NOTIFY Eo E Prix | | | | 
RET SEV M x | | 
ENVID 5:25 4. T x 
ORCPT [5.21 IT] | |x} | | 
SIZE Em Prix | | | | 
ENHANCEDSTATUSCODES [S208 Ir] |x| | | | 
PIPELINING |524 Ir] |x| | | | 
CHUNKING E H | x | | 
BINARYMIME aaa l| | E | | 
ESMTP-SMTP Downgrading | RACE MP IO 
send delivery report upon downgrade p PS | | | | 
Directory Address Resolution | | | | | 
provide facility to resolve addresses 6 C x 
use headers to populate local directory i I^ | l^ | 
Management Protocols: | | | | | | | 
Network management (Tol |r] | fx] | 
——'———— |----------]-|-]-|-|-|-1- 
Footnotes: 
1. SHOULD leave blank if all recipients are not known or resolvable. 
2. If a sensitive message is received by a system that does not 


support sensitivity, then it MUST be returned to the originator 
with an appropriate error notification. Also, a received 
sensitive message MUST NOT be forwarded to anyone. 

3. If the additional header fields are not understood they MAY 
be ignored. 

4. When binary transport is not available. 

5. When binary transport is available. 
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6. Other un-profiled contents MUST only be sent by bilateral 
agreement. 

If fax is supported. 

If the fax content cannot be presented it MAY be dropped. 
9. Handling of a vCard in text/directory is no longer defined. 


oo N 


13. Appendix B - Example Voice Messages 


The following message is a full-featured message addressed to two 
recipients. The message includes the sender's spoken name, spoken 
subject and a short speech segment. The message is marked as 
important and private. 


To: +19725551212@vm1 .mycompany.com 

To: +16135551234@VM1.mycompany.com 

From: "Parsons, Glenn" <12145551234@VM2 .mycompany.com> 

Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 

MIME-Version: 1.0 (Voice 2.0) 

Content-type: Multipart/Voice-Message; Version=2.0; 
Boundary="MessageBoundary" 

Content-Transfer-Encoding: “bit 

Message-ID: 123456789 VM2 .mycompany .com 

Sensitivity: Private 

Importance: High 
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--MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice-Originator-Spoken-Name 
Content-Language: en-US 

Content-ID: part1@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) 
fgdhgddlkgpokpeowrit09== 


--MessageBoundary 

Content-type: Audio/32KADPCM 
Content-Transfer-Encoding: Base64 
Content-Disposition: inline; voice-Spoken-Subject 
Content-Language: en-US 

Content-ID: part2@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Subject data) 
fgdhgddlkgpokpeowrit09== 


--MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Description: Brand X Voice Message 

Content-Disposition: inline; voice-Voice-Message; filename=msgl.726 
Content-Duration: 25 


ilililjMzN3czdze3s7d7fwfHhcvESJVe/A4yEhLz8/FOQjVFRERCESL/zqrq 
(This is a sample of the base64 message data) zb8tFdLTQtl1PXj 
u7wjOyRhws-tkrdns7RjuOt4tLF7cEOKOMxOTOnRW/Pn30c8uHi9-- 


--MessageBoundary- - - - 


The following message is a forwarded single segment voice. Both the 
forwarded message and the forwarding message contain the senders spoken 
names. 


To: +12145551212@vm1.mycompany.com 

From: "Vaudreuil, Greg" <+19725552345@VM2 .mycompany.com> 

Date: Mon, 26 Aug 93 10:20:20 -0700 (CDT) 

MIME-Version: 1.0 (Voice 2.0) 

Content-type: Multipart/Voice-Message; Version=2.0; 
Boundary="MessageBoundary" 

Content-Transfer-Encoding: “bit 

Message-ID: ABCD-1234567890VM2.mycompany.com 


Vaudreuil & Parsons Standards Track [Page 44] 


RFC 3801 VPIMv2 June 2004 


--MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice-Originator-Spoken-Name 
Content-Language: en-US 

Content-ID: part3@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) 
fgdhgd dlkgpokpeowrit09== 


--MessageBoundary 

Content-type: Audio/32KADPCM 

Content-Description: Forwarded Message Annotation 
Content-Disposition: inline; voice-Voice-Message 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is the voiced introductory remarks encoded in base64) 
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokO90gOQ5tkjpokfgW 
dlkgpokpeowrit09== 
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--MessageBoundary 
Content-type: Message/RFC822 
Content-Transfer-Encoding: 7bit 


To: +19725552345@VM2 .mycompany.com 

From: "Parsons, Glenn, W." <+16135551234@VM1.mycompany.com> 

Date: Mon, 26 Aug 93 8:23:10 -0500 (EST) 

Content-type: Multipart/Voice-Message; Version-2.0; 
Boundary="MessageBoundary2" 

Content-Transfer-Encoding: “bit 

MIME-Version: 1.0 (Voice 2.0) 


--MessageBoundary2 

Content-type: Audio/32KADPCM 

Content-Transfer-Encoding: Base64 

Content-Disposition: inline; voice-Originator-Spoken-Name 
Content-Language: en-US 

Content-ID: part6@VM2-4321 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is a sample of the base-64 Spoken Name data) fgdhgd 
dlkgpokpeowrit09-- 


--MessageBoundary2 

Content-type: Audio/32KADPCM 
Content-Disposition: inline; voice-Voice-Message 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadasssdasddasdasd 
(This is the original message audio data) fgwersdfmniwrjj 
jrgoij3045itj09fiuvdkjgWlakgQ93ijkpokfpgokQ90gO5tkjpokfgw 
dlkgpokpeowrit09== 


--MessageBoundary2-- 


--MessageBoundary-- 
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The following example is for a DSN sent to the sender of a message by 
a VPIM gateway at VMl.company.com for a mailbox which does not exist. 


Date: Thu, 7 Jul 1994 17:16:05 -0400 

From: Mail Delivery Subsystem <MAILER-DAEMON@vm.company.com> 

Message-ID: <199407072116.RAA14128@vm1.company.com> 

Subject: Returned voice message 

To: 2175552345@VM2 .mycompany.com 

MIME-Version: 1.0 

Content-Type: multipart/report; report-type=delivery-status; 
boundary="RAA14128.773615765/VM1.COMPANY.COM" 


-—-RAA14128.773615765/VM1.COMPANY.COM 

Content-type: Audio/32KADPCM 

Content-Description: Spoken Delivery Status Notification 
Content-Disposition: inline; voice= Voice-Message-Notification 
Content-Transfer-Encoding: Base64 


glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 
(This is a voiced description of the error in base64) 
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokO90gdffkjpokfgW 
dlkgpokpeowrit09-- 


--RAA14128.773615765/VM1.COMPANY.COM 
Content-type: Message/Delivery-Status 


Reporting-MTA: dns; vml.company.com 


Original-Recipient: rfc822; 2145551234@VM1.mycompany.com 
Final-Recipient: rfc822; 2145551234@VM1.mycompany.com 
Action: failed 

Status: 5.1.1 (User does not exist) 

Diagnostic-Code: smtp; 550 Mailbox not found 
Last-Attempt-Date: Thu, 7 Jul 1994 17:15:49 -0400 
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--RAA14128.773615765/VM1.COMPANY.COM 
content-type: Message/RFC822 


[original VPIM message goes here] 
--RAA14128.773615765/VM1.COMPANY .COM-- 


The following example is for an MDN sent to the original sender for a 
message that has been played. This delivered VPIM message was 
received by a corporate gateway and relayed to a unified mailbox. 


Date: Thu, 7 Jul 1994 17:16:05 -0400 

From: "Greg Vaudreuil" <22722@vm.company.com> 

Message-ID: <199407072116.RAA14128@exchange.company.com> 

Subject: Voice message played 

To: 2175552345@VM2 .mycompany.com 

MIME-Version: 1.0 

Content-Type: multipart/report; 
Report-type=disposition-notification; 
Boundary-"RAA14128.773615765/EXCHANGE . COMPANY . COM" 


--RAA14128.773615765/EXCHANGE . COMPANY . COM 

Content-type: Audio/32KADPCM 

Content-Description: Spoken Disposition Notification 
Content-Disposition: inline; voice= Voice-Message-Notification 
Content-Transfer-Encoding: Base64 
glslfdslsertiflkTfpgkTportrpkTpfgTpoiTpdadadffsssddasdasd 
(Voiced description of the disposition action in base64) 
jrgoij3o45itj09fiuvdkjgWlakgQ93ijkpokfpgokO90gdffkjpokfgW 
dlkgpokpeowrit09== 


--RAA14128.773615765/EXCHANGE . COMPANY . COM 
Content-type: Message/Disposition-Notification 


Reporting-UA: gregs-laptop.dallas.company.com (Unified FooMail 3.0) 
Original-Recipient: rfc822;22722@vm.company.com 

Final-Recipient: rfc822;Greg.Vaudreuil@foomail.company.com 
Original-Message-ID: <199509192301.12345@vm2.mycompany.com> 


Disposition: manual-action/MDN-sent-automatically; displayed 


--RAA14128.773615765/EXCHANGE . COMPANY . COM 
Content-type: Message/RFC822 


[original VPIM message goes here] 


--RAA14128.773615765/EXCHANGE. COMPANY . COM--— 
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14. Appendix C - Example Error Voice Processing Error Codes 


The following common voice processing errors and their corresponding 
status codes are given as examples. The text after the error codes 
is intended only for reference to describe the error code. 
Implementations should provide implementation-specific informative 
comments after the error code rather than the text below. 


RFC 1893 Error codes 


Error condition 


Analog delivery failed 4.4.1 Persistent connection error 
because remote system is busy - busy 


Vaudreuil & Parsons 


Analog delivery failed 
because remote system is 
ring-no-answer 


Remote system did not answer 


AMIS-Analog handshake ("D" in 


response to "C" at connect 


time) 


Mailbox does not exist 


Mailbox full or over quota 


Disk full 


Command out of sequence 


Frame Error 


Mailbox does not support FAX 


Mailbox does not support TEXT 


Sender is not authorized 


Standards Track 


.4.1 Persistent protocol error 


- no answer from host 


.5.5 Permanent protocol error 


- wrong version 


.1.1 Permanent mailbox error 


— does not exist 


.2.2 Persistent mailbox error 


- full 


.3.1 Persistent system error 


- full 


.5.1 Permanent protocol error 


— invalid command 


.5.2 Permanent protocol error 


- syntax error 


.6.1 Permanent media error 


- not supported 


.6.1 Permanent media error 


- not supported 


.7.1 Permanent security error 


- sender not authorized 
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Message marked private, but 5.3.3 Permanent system error 
system is not private capable - not feature capable 


15. Appendix D - Example Voice Processing Disposition Types 


The following common voice processing disposition conditions and 
their corresponding MDN Disposition (which contains the disposition 
mode, type and modifier, if applicable) are given as examples. 
Implementers should refer to [MDN] for a full description of the 
format of message disposition notifications. 


Notification event MDN Disposition mode, type & modifier 


Message played by recipient, manual-action/MDN-sent-automatically; 
receipt automatically returned displayed 


Message deleted from mailbox manual-action/MDN-sent-automatically; 
by user without listening deleted 

Message cleared when mailbox manual-action/MDN-sent-automatically; 
deleted by admin deleted/mailbox-terminated 


Message automatically deleted automatic-action/ 
when older than administrator MDN-sent-automatically; deleted/ 


set threshold expired 

Message processed, however manual-action/MDN-sent-automatically; 
audio encoding unknown - processed/error 

unable to play to user Error: unknown audio encoding 


16. Appendix E - IANA Registrations 


There are no changes to the registration per [DISP] of the voice 
content disposition parameter defined in the earlier VPIM V2 
document, RFC 2421. There are no changes to the registration per 
[MIME4] of the Multipart/voice-message content type defines in the 
earlier VPIM v2 document, RFC 2423. 


Both are presented here for information. 
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16. 


16. 


1. Voice Content-Disposition Parameter Definition 

To: IANA@IANA.ORG 

Subject: Registration of new Content-Disposition parameter 
Content-Disposition parameter name: voice 

Allowable values for this parameter: 


Voice-Message - the primary voice message, 

Voice-Message-Notification - a spoken delivery notification 
or spoken disposition notification, 

Originator-Spoken-Name - the spoken name of the originator, 

Recipient-Spoken-Name - the spoken name of the recipient if 
available to the originator and present if there is ONLY one 
recipient, 

Spoken-Subject- the spoken subject of the message, typically 
Spoken by the originator 


Description: 


In order to distinguish between the various types of audio contents 
in a VPIM voice message a new disposition parameter "voice" is 
defined with the preceding values to be used as appropriate. Note 
that there SHOULD only be one instance of each of these types of 
audio contents per message level. Additional instances of a given 
type (i.e., parameter value) may occur within an attached forwarded 
voice message. 


2. Multipart/Voice-Message MIME Media Type Definition 

To: ietf-types@iana.org 

Subject: Registration of MIME media type 
Multipart/voice-message 

MIME media type name: multipart 

MIME subtype name: voice-message 


Required parameters: boundary, version 


The use of boundary is defined in [MIME2] 
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The version parameter that contains the value "2.0" if 
enclosed content conforms to [VPIM2R2]. The absence of this 
parameter indicates conformance to the previous version 
defined in RFC 1911 [VPIM1]. 


Optional parameters: none 

Encoding considerations: “bit, 8bit or Binary 

Security considerations: 
This definition identifies the content as being a voice 
message. In some environments (though likely not the 
majority), the loss of the anonymity of the content may be a 
security issue. 

Interoperability considerations: 
Systems developed to conform with [VPIM1] may not conform to 
this registration. Specifically, the required version will 
likely be absent, in this case the recipient system should 
still be able to accept the message and will be able to 
handle the content. The VPIM vl positional identification, 


however, would likely be lost. 


Published specification: 
This document 


Applications that use this media type: 
Primarily voice messaging 

Additional information: 

Magic number(s): none 

File extension(s): .VPM 

Macintosh File Type Code(s): VPIM 


Person & email address to contact for further information: 


Glenn W. Parsons 
gparsons@nortelnetworks.com 


Gregory M. Vaudreuil 
gregv@ieee.org 


Intended usage: COMMON 
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Author/Change controller: 
Glenn W. Parsons & Gregory M. Vaudreuil 
17. Appendix F - Change History: RFC 2421 (VPIM V2) to this Document 
The updated profile in this document is based on the implementation 
and operational deployment experience of several vendors. The 
changes are categorized as general, content, transport and 
conformance. They are summarized below: 


1. General 


- Various and substantial editorial updates to improve 
readability. 


- Separated send rules from receive rules to aid clarity. 


- Clarified the behavior upon reception of unrecognized content 
types expected with the interworking between voice and unified 
messaging systems. (E.g., Unsupported non-audio contents should 
be discarded to deliver the audio message.) 


- Reworked the sensitivity requirements to align them with X.400. 
Eliminated dependencies upon the MIXER documents. 


- Reorganized the content-type descriptions for clarity 
2. Content 
- Changed handling of received lines by a gateway to SHOULD NOT 
delete in a gateway. In gateways to systems such as AMIS, it is 
not possible to preserve this information. It is intended that 
such systems be able to claim conformance. 
- Eliminated the vCard as a supported VPIM V2 content type. 
- Merged in text from RFC 2423 (Multipart/voice-message) 
3. Transport 
- None 


4. Conformance 


- Aligned the table of Appendix A to the requirements in the text. 
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